1. Technical Field
The present invention relates generally to an improved data processing system and, in particular, to a method and system for printing glyphs. Still more particularly, the present invention provides a method and system for rendering non-Latin1 Unicode glyphs in a virtual machine.
2. Description of Related Art
Almost all computer programs which have a graphical user interface or which display text to a user employ some type of character display subsystem. In recent years, these display methods have become more sophisticated, and new terminology has arisen to satisfy the need for more precise concepts. Many applications currently refer to glyphs, characters, and fonts.
It is important that one understand the separate concepts behind the words xe2x80x9ccharacterxe2x80x9d, xe2x80x9cglyphxe2x80x9d, and xe2x80x9cfontxe2x80x9d. A xe2x80x9ccharacterxe2x80x9d is a symbol that represents items like letters and numbers in a given writing system, for example, lowercase-g. When a given character is drawn on a presentation medium, a shape is presented which represents the character. This shape is called a xe2x80x9cglyphxe2x80x9d. A font is a collection of glyphs.
Characters and glyphs do not have a one-to-one correspondence. As an example, lowercase-a-acute can be represented by two glyphs: lowercase-a and acute. Another example is ligatures, such as ligature-fi, which is a single glyph usually representing two characters: f and i. This lack of a one-to-one correspondence becomes an even larger problem when one moves from a Latin font to a non-Latin or Asian font.
A font is a collection of glyphs and may have many typefaces, e.g., heavy, medium, oblique, gothic, and regular. All of these typefaces have similar typographic features and can be recognized as members of the same family. In other words, a collection of glyphs with a particular style form a font face, a collection of font faces forms a font family, and a collection of font families forms the set of fonts available on a system.
Character encoding is a conversion table that maps characters codes to glyph codes in a font. For example, ASCII (American Standard Code for Information Interchange) is a common coding scheme found in most computers. The character encoding used in the Java(trademark) virtual machine is Unicode. For more information on Unicode, one may refer to http://www.unicode.org. It is expected that most virtual machines in the future will employ the Unicode encoding standard as it is designed to be a universal standard.
As Unicode is used in more applications, Java(trademark) applications will expect to be able to display and print both Latin1 and LatinS Unicode glyphs simultaneously. Some run-time environments do not support the printing of non-Latin1 Unicode text (e.g., double-byte character sets (DBCS), Latin5, and Eurocurrency) since an assumption was designed into some platforms that PCL5 or Postscript(trademark) device fonts could be used to support the printing of non-Latin1 Unicode text. In order to provide this printing capability, some applications resort to native program code, which is operating-system-platform specific and not portable. Another printer-based solution would be to download the entire font file to the printer, which is only supported on a few printers.
The majority of printers do not have device font support for DBCS countries, which occur most notably in Asia. Moreover, a device font solution to the problem must address the proprietary nature of hardware devices, especially for numerous printer manufacturers in the DBCS case. Various solutions for such printers include converting from other character encoding schemes to Unicode and double-byte parsing. Matching encoding schemes can be complicated and may depend on legacy native code, especially since new Unicode values would not be included in the legacy native code.
Since portability is the most touted feature of Java(trademark), all Java(trademark) applications, including those that produce printer-ready text data, also need to be portable, especially those applications which run on such platforms as network computer (NC) host terminals. In order for such applications to remain portable, a generic printing scheme for handling Unicode is needed.
Using the concept of off-screen rendering, a Unicode encoding value for a non-Latin1 glyph is converted into a bitmap image using Java(trademark) in order to print glyphs that are not supported by a printer. This invention uses the JDK application information together with the operating system""s information to perform a non-operating system specific or generic rendering of the non-Latin1 Unicode glyphs for use in printing the glyphs.
The solution provided by this invention is glyph-based instead of font-based and works within the current confines of Java(trademark) classes and methods. The invention is glyph-based as the determination of which method to use to print a glyph is made on a glyph-by-glyph basis, not on a font basis. It is primarily an extension of the Java language that exposes a host font manager, such as a TrueType(trademark) font engine, in such a way as to bring the bitmap of a glyph into an application or applet executing on the virtual machine.
This solution has the following additional advantages: independence, portability, flexibility, universality, and delectability. The solution is independent from the font support in the printer, since the required bitmap is obtained from the platform specific font manager (such as a TrueType(trademark) font engine or a bitmap font engine) in a platform-independent or generic manner. The solution is portable to other Java(trademark) Virtual Machines (JVM""s) and is flexible in the quality and speed of the rendering, which can be controlled by the user. Finally, the solution is universal since most printers can handle bitmaps and detectable since the print stream can be readily analyzed.